NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/2449

Internet Message Format | 1996-08-05 | 8.3 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.c
Subject: Re: C or C++ for a 14 year old?
Date: 21 Jan 1996 09:05:04 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <[e-mail]>,
pretzel  <[e-mail]> wrote:
>Allright, it's time to end all of this crap.  I *AM* a 14 year old and I
>*AM* learning how to program in C, and I can tell you that C is the best
>choice for beginners.  It teaches the programming fundamentals from the
>very start, unlike BASIC, which let's you do whatever you want, or
>Pascal, which is harder to find support for.  I had a hard time getting
>started in programming.  I was interested when I was 9 years old, but I
>didn't know where to go or even what I was looking for.  Eventually, I
>realized that my Tandy 1000 had a really neat thing on it called
>GW-BASIC, and things took off from there.  But it wasn't easy.  I learned
>how to program in BASIC from poorly written examples I found in
>magazines, and straight from the GW_BASIC manual.  I developed horrible
>habits (I used so many GOTOs that my programs looked like spaghetti).
>PLEASE, don't let this happen to your child!!  Start him/her on
>structured C programming from the very beginning!  I eventually abandoned
>basic, and started up with C.  I tried to learn it in the same way, and
>again developed nasty habits.  The absolute best thing that you can do is
>buy a good book.  I recommend "The Art and Science of C" by Eric S.
>Roberts.  It is the best text that I have ever seen on the subject, and I
>have looked through quite a few.  He takes the confusing elements of C
>and removes them completely by using his own custom function libraries
>which simplify things like input and strings.  Later, he teaches you how
>to do these things without his libraries.  He also teaches the aesthetic
>side of programming, and enforces good technique.

You might be interested in something that Edsger Dijkstra, a great computer
scientist you might one day learn about, once said about BASIC:

    It is practically impossible to teach good programming style to
    students that have had prior exposure to BASIC: as potential
    programmers they are mentally mutilated beyond hope of
    regeneration.

Dijkstra is known for many things, among which is the research into methods for
formally proving the correctness of algorithms using logical derivation.

Having said that, I'd also like to add that loong ago (about 16 or 17 years?) I
started out programming in BASIC and assembly language soon after that. I don't
think that I was impaired in any way. I took up Pascal and later C with no
problems.

BASIC teaches you how to decipher spaghetti code, which is a useful skill for
someone doing software maintenance. BASIC and assembly language have taught me
sheer perseverance, if nothing else.

I don't believe that using "goto" is bad. If you notice, the C language has it.
It also has things called function pointers, a mechanism that allows you to
store the address of a function inside a variable so that you can later call
it. You can store any address inside this pointer.

The C language alone is far too flexible to teach good program design and
implementation, but it certainly allows these to be practised.

The control structures of C are not fully general, meaning that the use of a
goto sometimes makes code simpler and clearer. There is no way to exit out of
a nested inner loop, for instance, since the "break" statement doesn't take an
argument. In the scripting language Perl, you can do "break 3;" to jump three
loops out. In C, you can do this by putting a label where you want it, and
doing a goto.

I have seen goto used in a lot of programs as a way of handling errors.
Suppose that you have a routine inside an operating system which needs to
allocate three different objects, but there is no support for doing it
atomically. What you do is try the first one. If the allocation doesn't fail,
you try the second, and if that doesn't fail you allocate the third. If that
doesn't fail, you go on with the rest of the routine. However, if any of the
allocations fail, you may want to back up and free the previous successful
allocations so that you don't cause a kernel memory leak. A good way to do this
is to have a bunch of nested gotos:

{
    if ((a = makea()) == FAIL)
        goto backout1;
    if ((b = makeb()) == FAIL)
        goto backout2;
    if ((c = makec()) == FAIL)
        goto backout3;

    /* success---do the rest     */

    return OK;

backout3:
    destroyc(c);
backout2:
    destroyb(b);
backout1:
    destroya(a);
    return FAIL;
}

This is far more elegant than having all kinds of "structured" code involving
multiple occurences of the same destroy() calls, and multiple return points
from the function. Of course, it might be better if you could somehow grab all
three objects at once in an "all or nothing" atomic call, but the software you
are interfacing with doesn't always work the way you would like it to.

The above has a definite structure that can't be called spaghetti code, despite
that it uses goto. Good programming transcends the particular capabilities of
the language you are using. These capabilities don't always lend themselves to
someone's idea of how programming ought to be done.

The idea that structured programming can replace "goto" is only a theoretical
result stemming from the 1960's research of people like Dijkstra. This does not
mean that in any particular language if you avoid the use of things like
"goto", your program will become smaller or clearer---only that it can be made
to work identically to the one using goto. This is an abstract result of a sort
of logical proof, which is misinterpreted by some people as a strict
programming guideline to abide by. It may have served well that way in the wake
of the "software crisis" of the 60's (which the authors software engineering
texts just *love* to mention).

If you look at the underlying machine code generated by your compiler, you will
find that it's peppered with branches, subroutine calls and jumps. The GNU
compiler will optimize some switch/case constructs using jump tables, which is
roughly analogous to the old ON X GOTO 1000, 1200, 1500 ... in BASIC. In fact,
the computer hardware basically works with nothing but GOTO's. I don't know of
any mainstream CPU architectures which support a lot fancy control structures
directly in hardware, and in cases where things resembling structures do exist,
they are often poorly exploited by compilers.

>    Sorry to be so long winded, but I have been following this debate
>for a while, and I was getting frustrated that no actually 14 year olds

Oh, so 13 and 15 year olds don't count, eh? How do you know how old anyone is?
I don't see too many contributors revealing their ages; even if many 14 year
olds frequent this group, they may not care to identify with you on the basis
of age alone.  Age is such a fleeting thing; as you get older, the difference
matters less, though when you are 14, an 18 year old looks ancient to you!

>were commenting.  In closing, I would like to state that if someone is

"In closing?" "long winded?". I _like_ that. You write pretty well. Not a lot
of fourteen year olds can produce a coherent piece of written language. Maybe
you should get over the "14" business and seek out like-minded people who share
your interests regardless of their age; the 'net is great for that! You may go
to a University one day, and will meet people of all ages, from the rare 14
year old taking third year mathematics, to the 50 year old who has decided to
go back to school.

>intelligent enough to want to learn how to program, then they are
>certainly intelligent enough to handle C.

Well now, just because someone _wants_ to learn how to program doesn't mean
that that person is intelligent. He or she may be attracted by the perception
that programmers are intelligent, but eventually give up when faced with
overcoming the challenges.  There are such "wannabees" in almost every field.

There are many ways to enter the study of computing; learning a system
programming language is not the only way. Some schools teach LISP-like
languages, such as Scheme, to beginners, for instance. Others still rely on
Pascal, Modula-2 and such.
--